databasemanagementfandomcom-20200214-history
Navigational Database
A navigational database is the combination of both the hierarchical and network model of database interfaces. Navigational techniques utilize “pointers” and “paths” to navigate among data records. The opposing model is the relational, which uses “declarative” techniques in which you ask the system for what you want instead of how to navigate to it. Traditionally navigational interfaces are procedural, though one could characterize some modern systems like XPath as being simultaneously navigational and declarative. The Hierarchical model is considered navigational because it is necessary to navigate up and down to “parents” and “children”. In addition to that, file/folder paths are considered “paths” in the navigational model that are followed to the proper location. For instance, with the navigational model, one may ask for the location of a “record” down the hall, 3 doors to the left, in the back of the room, on top of the filing cabinet. This is opposed to the relational that may ask for all records in a filing cabinet. In general, navigational systems will use combinations of paths and prepositions such as "next", "previous", "first", "last", "up", "down", etc. Navigational models are allegedly derived from a speech by Charles Bachman in which he describes the "programmer as navigator" while accessing his favored type of database. Some criticism of navigational techniques includes the comparison to the “Go to” of pre-structured programming and the undisciplined method of the model. The downfall of this “Go to” methodology is that it is very unorganized. In this sense, the relational model is a much more efficient one to use in large scale operations. But, in practice relational has yet to successfully scale down to smaller-use data. Whether this is an in-born fault of relational, or just lack of implementation improvement research is difficult to say at this point. Some fault the SQL language rather than relational theory in general. That being said, navigational techniques are still the preferred way to handle smaller-scale structures. "Paths" are often formed by concatenation of node names or node addresses. Example: Sample database nodes: A labeled graph on 6 vertices and 7 edges. (Numbers are used for illustration purposes only. In practice more meaningful names are often used. Other potential attributes are not shown.) Node6.Node4.Node5.Node1 Or Node6/Node4/Node5/Node1 If there is no link between given nodes, then an error condition is usually triggered with a message such as "Invalid Path". The path "Node6.Node2.Node1" would be invalid in most systems because there is no direct link between Node 6 and Node 2. It has been suggested that navigational database engines are easier to build and take up less memory (RAM) than relational equivalents. However, the existence of relational or relational-based products of the late 1980s that possessed small engines (by today's standards) because they didn't use SQL suggests this is not necessarily the case. A current example of navigational structuring can be found in the Document Object Model (DOM) often used in web browsers and closely associated with JavaScript. The DOM "engine" is essentially a light-weight navigational database. The World Wide Web itself and Wikipedia could potentially be considered forms of navigational databases, though they focus on human-readable text rather than data (on a large scale, the Web is a network model and on smaller or local scales, such as domain and URL partitioning, it uses hierarchies). In contrast, the Linked Data facet of the Semantic is specifically concerned with network-scale machine-readable data, and follows precisely the 'follow your nose' paradigm implied by the navigational idea.